In the art of computer programming, there are various tools to assist with the designing of a software program (e.g. application program). One category of such program design tools is the visual modeling type. The UML is an example visual modeling language (with formal syntax and semantics) for communicating a model or conceptionalization. The modeling language specification specifies modeling elements, notation and usage guidelines and not order of activities, specification of artifacts, repository interface, storage, run-time behavior and so forth.
In general, at the modeling level a “problem” is posed in terms of a customer's needs and requirements and may be referred to as the business problem system. The software designer develops a “solution” software product and or service that addresses the problem. The UML syntax enables software designers to express (specify and document) the subject problems and solutions in a standardized manner, while the UML semantics enable knowledge about the subject system to be captured and leveraged during the problem solving phase. See “UML in a Nutshell” by Simon Si Alhir, published by O'Reilly & Associates, September 1998. As such, the UML enables the sharing of information (including prior solution portions) and extension (without reimplementation) of core object oriented concepts (analysis and design) during the iterative problem-solving process for designing software products.
Connection tree routing in a visual modeling language is where the connector/edges are routed in an orthogonal manner and connect into a common tree trunk. The appearance is such that the connectors appear as branches from a set of nodes onto a “trunk” that targets a single node.
Briefly, “oblique routing” refers to connection routing that is not constrained orthogonally. “Bendpoints” are point locations in a connection that a line is routed through. “Router” is a class that manages the layout of the connection constrained to the bendpoints. “Node” is a shape on a diagram that can be connected to other nodes via a connection. A “connection” is a line on a diagram that connects two nodes together.
Connection Tree Routing is a technique utilized in a visual modeling diagram where a hierarchical view of the nodes on the diagram is necessary. The relationships between the nodes have to be directed such that no cycles exist when traversing them. Also, for any given node, the incoming edges can only be [0 . . . 1], that is, none or one. An example of where this style of routing is used is in UML Class Diagrams where the nodes are classes and the connections represent generalizations between the classes on the diagram.
This is usually represented in memory as a central trunk element that each connection connects to. As demonstrated in FIG. 1, the solid line portion represents the “trunk” 19 and the dashed line connections 13 are attached to the trunk 19 to form the connection tree routing 17.
The problems with this arise in a number of areas:
1. Ensuring that connections keep synchronized in response to user movements in one or more of the participating connections. Moving one of the connections in the tree can destroy the integrity of the tree. Implementations to address this often over complicate the use cases for reorient and deletion of connections participating in the tree by managing the tree through the central “trunk” element. The “trunk” element is overloaded with responsibility in that it has to listen to all the participating connections, and manage attachment locations and changing connection
2. Support for multiple tree connection structures is not automatic—i.e. each tree has to be manually moved and manipulated out of the way of the other tree. The central “trunk” element described above would need knowledge of other participating “trunks” and adjust itself accordingly. The issue is then which tree trunk element is designated as prime in order to adjust overlap between trunks.
3. The connections have to be in the direction of the view they are targeting (“trunk”) versus the actual view the connection is logically connecting to. Special code has to be in place in order to understand that the real semantic target is the node that the trunk is connected to, not the “trunk”.
4. Persistence of this structure is not intuitive causing potential team scenario issues. What is the “trunk” persisted as in the model file, is it a node or a special case of a connection? This also causes issues with team based scenarios where 2 or more team members are modifying the same diagram file. If one team member changes the router to “oblique” style and another changes the router to “tree”, the resulting file difference between the 2 file changes would be considerable (new element+new target view) and is not easily understood by the merge integrator. The intuitive change would be a minor style change to route the connection differently.